Going back over it again, I was able to get the "9100" software to run and program the radio, it also can run in the 136-174mhz as well I have it receiving KIH-35 on 162.5500, and I need to check it for transmit on when I get to one of my MURS radios.

I can offer a radio for development as soon as the one I ordered gets here from China.

I would love to be able to use CHIRP on this radio.

I just received one of these. It is a Dual Band HT, covering VHF: 136-174MHz and UHF: 400-470MHz.

How can we get it added to CHIRP?

Just adding my support for adding this lovely little unit to CHIRP. And many thanks for uploading the 9100 software. I bought the programming software for the unit from Banggood, but couldn't get any of it to work! The 9100 works fine, but it would be great to bring the capability into CHIRP.

Thanks for uploading the 9100 software. The 9100 works fine, but it would be great to bring the capability into CHIRP.

+1 for chirp support for Baofeng 9100 / T1 Mini. 73, EA5IGC

Willing to donated BF-T1/BF-9100A and/or lend same plus BF-Mini for inclusion in CHIRP.

Wow...

I wrote my comment without actually "see" the BAOFENG BF-T1 radio (google search) it can even pass as a toy walky-talky radio by any custom check point in the world... hi hi hi...

I'm looking the files uploaded and the protocol and memory layout is really trivial compared to the UV-5R and the BTECHS.

Does any of you a link for the user manual that can pass it to me/paste here?

Cheers, Pavel CO7WT.

It's 9600 8N1, but the UART is in the cable. You don't need a driver for the radio. The cable uses the same driver as all my other Baofeng and TYT cables.

To be clear, the programming cable is not the one that comes with the radio, that one is a charge only cable. The actual programming cable is available separately and contains a prolific pl2303 usb-serial chip.

I am happy to assist with any testing.

Hi guys!
Thank you!
I'm ready to test the program.
Link to the instruction in English.
http://www.radioscanner.ru/files/download/file20279/baofeng_bf-t1_-_users_manual.pdf

Link to the list of channels.
http://www.radioscanner.ru/files/download/file20094/bf-t1-zavodskie.zip
Open in the programming Software 9100_En_Setup.exe

Topic in forum (in Russian)
http://lpd.radioscanner.ru/topic26647.html

Hello Pavel!
Do you speak Russian?
I could not open the module bf-t1.py
Windows10 x64 chirp-daily-20171204
Error
!http://i12.pixs.ru/storage/7/1/6/errorpng_5531146_28625716.png!

The new file does not work. The same error.

Dmitry Milkov wrote:

Hello Pavel!
Do you speak Russian?
I could not open the module bf-t1.py
Windows10 x64 chirp-daily-20171204
Error

Hello Dimitry.

Sadly no, beside my Russian originated name I can only do a "slight" read in Russian as I received a few lessons here in the school in Cuba at a very young age; but then they switched to teach english. It was in the 90' when the URSS fall apart... you know the background.

Only Spanish (Mother language) and English as acquired one here.

About the error you are getting, don't worry it's a common mistake: you need to open the link and then click on download to get the real .py file.

If you do a right click & then save over the link, you get a html page saved as a .py and hence the error. Try to open it on a separate window and click the download link.

I will be in front of the PC connected to the internet for about an hour from now, if you do it now I can get it to work it at night, if not I will get it tomorrow... I have Internet only in public WIFI parks, not at home.

73 Pavel CO7WT.

Lance Clarke wrote:

My error was different this time. Files attached.

Error but PROGRESS !!!

We have a validated and identified radio successfuly.

The radio refused (or don't has time) to respond to the query for the eeprom data...

I'm reviewing the pcap files to see if I missed something...

Keep an eye on this, we have make the first step.

73 Pavel CO7WT.

Please let me know if there is anything else I can do to help.

Thanks for everything you're doing!

This are the problems that the users don't see in the development process... fine tuning the vars and timeouts.

I would like to see if any other user has this problem...

Dimitri can you test it?

I will take a deep dive in the serial logs once again to see if I missed something.

73 Pavel CO7WT

Ok, this is a strange error.

As per the pcap USB serial log and the serial log attached to this thread I can't identify any different from what we are doing now.

I would ask a few questions to get an idea of what to expect.

With the OEM software the radio does reboot or makes any strange behavior in the reading process?¶

Does the read process with the OEM software run smoothly? (no appreciable stop or pause in the progress bar or the entire read process)¶

Can any of you produce a short video of the download process with the OEM software showing both the radio and the PC screen for me? (a youtube link will be enough, no need to upload it here)¶

Thanks in advance for your comments.

73 Pavel CO7WT.

1. My reads quickly and smoothly. It takes 2-3 seconds then the radio reboots when done.
2. Yes, very quickly and smoothly.
3. I cannot, no. Sorry.

https://youtu.be/CrG2RWnfvqo

Deleted the mem explore example, it has not reason to be until we have a full featured comm with the radio.

73 Pavel CO7WT.

Thanks for the test Lance.

Without a radio to test in my hands I'm really just stalled here. I have a few test in my mind but all of them will be just to slow and painful to make with this asynchronous schema.

I'm placing a note on the developer list to bring a few pairs of fresh eyes to this issue (and possibly a developer with one of this radios).

Will take a new look this night at home and will report back tomorrow.

73 Pavel CO7WT.

Do you use TeamViewer? You could take control of my PC remotely and do what ever you need to do.

It would be great if we had Chirp support for BF-T1. Especially that I am not sure if it is safe to install Baofeng software (i.e. 9100_En_Setup.exe). VirusTotal shows 2 trojans (hard to say if it is false-positive):

• https://www.virustotal.com/#/file/933385b7fd8f90cbf9d87196a310f96ccc6f93f34620339ba43714df623d725a/detection

I would be happy to help with testing, but I have ordered programming cable today, so it will take some time until I receive it.

Lance Clarke wrote:

Do you use TeamViewer? You could take control of my PC remotely and do what ever you need to do.

Good Idea...

Drop me and email, click on my name on any of my posts to get the details.

73 Pavel CO7WT

Thanks Harold, that proves that a fresh pair of eyes always see more... hi hi hi...

Dimitri & Lance, can you test the procedure described with this driver?

Harold: yes, channel data can be wrong, I was only testing the communication between radio and PC, now with a save from chirp of the data in the test.dat I can start to reverse engineer the mem layout.

Please can you do the procedure described here https://chirp.danplanet.com/issues/4933#note-27 for me and attach the chirp image file?

73 Pavel CO7WT.

Tom M wrote:

It would be great if we had Chirp support for BF-T1. Especially that I am not sure if it is safe to install Baofeng software (i.e. 9100_En_Setup.exe). VirusTotal shows 2 trojans (hard to say if it is false-positive):

• https://www.virustotal.com/#/file/933385b7fd8f90cbf9d87196a310f96ccc6f93f34620339ba43714df623d725a/detection

I would be happy to help with testing, but I have ordered programming cable today, so it will take some time until I receive it.

At least the copy on this issue thread is virus safe, check this link: https://www.virustotal.com/#/url/f8323802df0958c905f4f509c43cee4f84208e0878340560eaa7f1afd7d68c84/details

It appears that you get an infected copy some here...

Cheers

Lance Clarke wrote:

I tried using bf-t1 (hwh).py but got the same error as before.

Are we facing driver/OS/Python issues here?

It works on linux but not in Windows? (Dimitry and lance are working on WinVista/7 with python 2.7) Harold on Linux.

Hum...

I'm thinking out of the box after reviewing the videos and making some math here...

Please test this - fast as hell driver - driver... https://chirp.danplanet.com/attachments/3917/bf-t1.py

73 Pavel CO7WT

Pavel,

The fast version doesn't like the cHB format in make_frame.

File "/home/hwh/Desktop/t1-driver/bf-t1 (pavel-fast).py", line 126, in _make_frame
frame = struct.pack(">cHB", ord(cmd), addr, BLOCK_SIZE)
error: char format require string of length 1

I suspect ord doesn't return a char but I'm not really great with python.

On the other things, if I load test.dat into the 9100 oem software I'm using it doesn't error but nothing on the screen changes, it still shows the setup and frequencies I already had programmed. The about on the software I'm using says "9100 Program software, 1.3, 9100. I don't remember where it came from, I've been using it for a couple of months.

Test.dat looks like it was hand generated. It's using the non-US comma as the decimal point in the frequencies instead of using a period. Since it's a comma delimited file that appears to be confusing the program. All the files I saved with the program use periods. I'm hand changing it to periods to test it, give me a few minutes.

Ah, yes. I did a global replace of ",00000" with ".00000" and that seems to have fixed it.

Harold,

What driver file are you using?

The one I posted in https://chirp.danplanet.com/issues/4933#note-58 It works on linux, I don't have chirp loaded on windows currently to test it there.

Harold,

Please let me know if there is anything I can do to help.

Hi everybody, good morning.

I have read all the posts, we have a working driver then. I have collected all the data and will be back as soon with a more accurate driver (for the channel data)

I saw the difference in the data that Dimitry highlighted, that's why I need the img that correspond to the .dat from the OEM, to check this little details and fix it.

I noted also the >B/>c from Harold as the , by . substitution.

I will work on that issues an will be back ASAP. Thanks four your time and test.

73 Pavel CO7WT.

Dmitry,

I wonder if Lance's problem is related to your USB3 problem. What error does it give you on USB3?

Thanks Dmitry, that is identical to Lance's problem, the error in his logs is the same as your log. It can read the radio id but times out and fails when it tries to read the memory.

Lance, have you tried different USB ports? Maybe the port you're using is the problem.

Lance,
Your file is working!
I have the same file.
MD5: 3781bdd4587eb1d87b7026fc2bbe96e7

It works on my three computers.
Laptop with Windows XP sp3
PC with Windows 7 x64
PC with Windows 10 x64

Dmitry,

Thanks for checking. I don't know... I guess I am just out of luck on this one.

Lance,

You're not alone, I just tried all three usb ports on a win10/64 laptop and get the same error. Since it consistently doesn't work for me I may be able to figure out why. On another open source project (LibrePilot) we had something similar where something related to USB serial ports worked on linux/mac but not on windows.

Hi OMs, can any of you make a test for me?

The task is to find the sweet spot for the timeout value.

Please remove or comment the line #267:

radio.pipe.timeout = 3   # 3 seconds.

And then try to download the image from the radio, if you get in trouble just increase the vale on the line #42:

STIMEOUT = 1

Then even if the STIMEOUT is nice, try to get it to the real sweet spot by lowering it in discrete steps until you receive and error, then step up to a higher working value...

Once you get this value on one Operating System (Linux Mint?), please try it on other (Windows 10?) tweaking it if needed.

As per the serial logs I think that the real value for the timeout must lay in the range of 0.04 to 0.2 but without a radio at hand is difficult for me to try that.

Please report back the value to include it in the final value.

I'm working on the channel data now.

73 Pavel CO7WT.

Also, I have progress in the channel data identification but I'm lacking some vital data.

Can any of you make and post a .dat (OEM) file and the corresponding .img (chirp) for this use cases:

A channel with a tx split below the RX (example: RX 145.170 TX 144.570) No tone set.¶

A channel with a tx split above the RX (example: RX 443.500 TX 449.500) No tone set.¶

A pair of channels programed as simplex (no split) where the only difference is the Wide/Narrow bandwidth (Same freq, no tone)¶

A pair of channels programed as simplex (no split) with the same DIGITAL tone on RX/TX but different in the polarity (one D###N and the other D###I, no matter what ### if it's the same on both)¶

A pair of channels programed as simplex (no tone) where the only difference is the Scan (one ON the other OFF)¶

Thanks in advance for your cooperation.

This test are needed to find what combinations of bits are each setting.

73 Pavel CO7WT.

Dmitry Milkov wrote:

STIMEOUT = 0.04 - error
STIMEOUT = 0.05 - Not stable. Reading is not always.
STIMEOUT = 0.06 - ОК

Roger, thanks for the test, will set it 0.07 to be safe.

73 Pavel CO7WT.

Lance,
I have the same settings. But I have another adapter.
I do not work Prolific on Win10 with BF-T1.
!http://i12.pixs.ru/storage/3/9/6/Image2png_1437982_28638396.png!

How are you using a different UART? I'm using the Baofeng cable that came with the radio.

I just tried on a second PC and with a second radio and I see exactly the same behavior. It reboots as soon as I click to read it.

Lance Clarke wrote:

How are you using a different UART? I'm using the Baofeng cable that came with the radio.

https://chirp.danplanet.com/issues/4933#note-20

Dmitry Milkov wrote:

Pavel,

Thank Dmitry, perfect timing... I'm working with the files you uploaded now...

Cheers Pavel.

I just tested and the changes in my previous post also work on a win7/32 laptop that wouldn't run the earlier versions. Hopefully this will fix it for all windows.

A question.

Can any of you please clarify the use of the Emergent and Relay CH ?

In he programming schema, channel 0 is the Emergent CH and the Relay CH is not processed yet.

I'm asking to decide the best way to handle this two "special" channels.

73 Pavel CO7WT.

Thanks, updating it and will post it ASAP

Pavel,

My offer of using TeamViewer still stands, if that would help you work on the settings.

Pavel,

The one you posted an hour ago works to both read and write. :⁾

I tested it on both linux and win10/64.

Harold Hankins wrote:

Pavel,

The one you posted an hour ago works to both read and write. :⁾

I tested it on both linux and win10/64.

Ok, I will wait for Lance and Dmitry testing before send it to Chirp in an official way.

Good news: A ham contact me by mail and he is working to ship one of this radios to me, full support is on his way people.

Thanks to this generous ham.

73 Pavel CO7WT.

Hi to all.
I tested the last file bf-t1.py. Reading and writing work. All OK. Win10 x64

Pavel Milanes wrote:

A question.

Can any of you please clarify the use of the Emergent and Relay CH ?
The radio has a separate button SOS. It the Emergent.

In he programming schema, channel 0 is the Emergent CH and the Relay CH is not processed yet.
It is right. I think so.

Relay CH - I do not understand why.

I suspect the "relay" channel has something to do with the mobile (car) radio the T1 was designed to work with. If you look at the picture of the back of it on "Banggood's Car/T1 Page":https://www.banggood.com/BAOFENG-T1-Car-Mobile-Transceiver-15W-UHF-400-470mhz-With-2-Pcs-Portable-Walkie-Talkie-SOS-Radio-p-1217566.html?p=SO28133399239201512V it shows a relay connector on the back.

I just placed an order for the last one they had in stock to check and see if I can learn more. They're quoting 8-10 days delivery but I expect it will take longer because of Christmas mail.

Hi to all.

I was searching the net to now better the two special CH in this radio and found that the BF-T1 (also known as BF-9100) is suspiciously similar to the BF-9200 (http://www.baofengradio.com/enProShowcn.asp?ID=364) they has almost the same description/features.

Maybe this driver also work with that one?

73 Pavel CO7WT

Pavel Milanes wrote:

Ok, I will wait for Lance and Dmitry testing before send it to Chirp in an official way.
It's working great for me now!

Hi Pavel,

Great work.
Tested it and so far so good. Worked out some of the settings, only the ones you can change from the menu on the radio.

this is the unknown0[16] array in settings.¶

byte 2 = squelch d0-d9
byte 3 = vox d0-d9
byte 4 = tx timer, d0 is off, d1-d6 time in 30 sec increments
byte 5 = multi setting register in binary form
backlight = bit1-bit0 > 00 =off, 01 = key, 10 = on
squelch tail = bit5 > 0 = off, 1 = on
busy lockout = bit4 > 0 off, 1 = on
key beep = bit3 > 0 off, 1 on
byte 6 = scan type, d0 = timed, d1 = carrier, d2 = stop
byte 9 = alarm ( count down timer ) d0 - d16 in half hour increments
byte 10 = voice prompt, d0 = off, d1 = english, d2 = chinese

byte 14 = relay mode, d0 = off, d2=re-tx,d1=re-rx ( but how it works?)¶

Other settings may follow, but 9100.exe.crashes on my main workstation.

regars

Henk

Harold Hankins wrote:

Pavel,

It's not really useful for Chirp but I think I found the firmware version. I'd guess it's June 8, 2016. The silkscreen on the board says Jan 24, 2016 so that would be reasonable. I've attached where to find it in case it's useful sometime.

[2017-12-13 19:16:11,027] chirp.ui.mainapp - INFO: Version '16.06.08 BF9100S'

Hi Harold,

0x06F0... hum...

Have you made a test to determine how big is the real firmware?

I'm interested in a .img of the entire size for the radio, can you made one and post it?

There are yet some issues with the fingerprint (I have used a "apparently" free space in a special location, but that's just a patch) and maybe we can improve that with a real full image.

A generous ham agreed to send me one of these radios next week, I hope it get to my hands by the end of the year or beginning of next one. But it's very interesting to see and try to reverse engineer the full image.

BTW, I have pushed the patch for this radio to the developer queue, it's time now for review and approval, so if all goes well we will have it in main Chirp for xmas. (Just channel support)

73 Pavel CO7WT.

Henk Groningen wrote:

Hi Pavel,

Great work.
Tested it and so far so good. Worked out some of the settings, only the ones you can change from the menu on the radio.
this is the unknown0[16] array in settings.
[....]
Other settings may follow, but 9100.exe.crashes on my main workstation.

regars

Henk

Hi Henk,

Thanks for the compliments, but they are not for me alone, the users of this thread are the main actors, I am only the conductor of the orchestra...

Just now you become a new player, thanks for the info, I will implement and validate that settings ASAP.

73 Pavel CO7WT.

Pavel,

The t1 has a 2k eeprom. I'm away from computer all day but I'll post full dump tonight.

Pavel Milanes wrote:

Thanks for the compliments, but they are not for me alone, the users of this thread are the main actors, I am only the conductor of the orchestra...

I do aknowledge everyones contribution, but still .. a master-conductor.

Anyway, some more settings for the unknown0 array:

--
byte 5
bit 2 keylock 0=off,1=on ( still changable from set when set on)
bit 7 battery save 0=off, 1=on
bit 6 fm-radio 0=off, 1=on ( off disables fm button on set )
byte 7 active channel, d1-d20, setting it works on upload
byte 8 , fm range , 1=low 65-76, 0=high 76-108
byte 11, volume d1-d7
( set to #FF by original software on upload, chirp uploads actual value so no max vol after prgm )

byte 15 tx pwr, 0 = low, 1 = high¶

This should cover all settings available through the original software.
byte 13 changes after an upoad from the 9100 software, not discovered what it means/does, yet.
There are other unused bytes in the array, but don't want to brick mine just now .. had it for two days.
Setting the relay-frequency in the browser and uploading seems to work too, even whithout shift. So seems to be just a normal channel without any specific use, as is the emergency channel. As for that channel: it seems to be a dual watch function, with emergency-reception overriding normal reception.

73 Henk PA3CQN

addition on byte 13:

byte 12 and 13 are the frequency of the fm receiver.
2 byte value, resulting frequency is 65 + value*0.1 MHz.
With byte 12/13 as #0145 that would be 65 + 325*0.1 = 97.5 MHz

73 Henk PA3CQN

Pavel,

That doesn't actually include the true firmware, the read command only reads the configuration eeprom. If you try to read past 2k it just wraps around and gives you starting over at the beginning.

There's probably another command we don't know to read/update the actual cpu firmware. The cpu is a Fujitsu MB95F013K and I haven't found a manual on it yet to see if I can find a way to read it.

Is it possible to expose the volume setting on the Settings Tab? I find it annoying that the volume always resets to the MAX any time you write to the radio.

Or if not expose it, at least have it maintain the user's current setting.

Henk Groningen wrote:

Lance,

It does on my version. You do need the second version I uploaded( that copes with the annoying max volume ).
I have no idea how to add inline images here, but it is the fifth option, using chirp daily-20171204.
And chirp keeps the volume.

I guess you are not seeing the volume? But you are seeing the settings tab?

73 Henk PA3CQN

Great! I haven't had a chance to try your version yet but I hope to later today.

Thanks!

Henk Groningen wrote:

Lance,

It does on my version.

Henk,

It's working great!

Thanks to all of you for your work.

Pavel, Dmitry, Harold, and yourself did the real work!
I will try and extend the settings with the fm_vfo. As for the band limits, I'm leaving that to someone else. I don't see the added value on a fixed frequency handheld.

It's a fun little radio to play with, and supprisingly sensitive on the reception side of things.
Ok, the headset is crap and not even working, and I do recommand the volume mod.
But for the 12 euro's I paid to get it delivered to the Netherlands it was money well spend.

Now the search for other hidden settings can begin. There must be some ..

Wow.

I get away for a while and miss a few things.

Harold and others, I have a full settings version working at home, I'm on my cell now, my version has all the validation un place, including the volumen bug, It has a small bug detected by the Chirp testbed.

I will work It tonigth and tomorrow Will publish the full versión.

Sorry for the typos, my cell force the spanish.

73 Pavel CO7WT

Pavel Milanes wrote:

Wow.

I get away for a while and miss a few things.

Harold and others, I have a full settings version working at home, I'm on my cell now, my version has all the validation un place, > including the volumen bug

Yeah, I skipped most validations since the only way to get wrong values is by setting them in the chirp browser.

fiy:

• you can set the fm vfo to any value from 65-108 at any time in software. The limits are only there for tuning on the bf-t1 itself
• the exact workings of the relay channel remain a mystery: however, it does function like any other channel. I programmed it through the settings browser, and it just works, regardless of tx/rx sync setting. The synchronisation indeed is for the 9100, but why? The BF-T1 sends out channel information on channel change, so the mobile set would be synchronized anyway.

Hi Pavel,

Nice work.
For my personal likings:

• I would leave the FM as is, without check, but it does not really matter to me
• I would remove the limits settings, they do not add anything of value as you cannot change the frequency on the set. Or at least move them to an advanced tab, they now clutter the settings tab. Of course they should be internally used to validate input for channels, but there is no need for the user to change them.
• I would set both emergency and relay channel to special channels. I looked at the setup from a UV-B5 this morning where vfo1 and vfo0 are special channels and it is not that difficult. If you download the UV-B5.py and search for 'SPECIALS' it will be easy to copy.
• the column polarity for DTCS is a questionmark. Has anyone tested if the set really can do that? It is not in the original software.
• the column cross mode is not really needed. But that is a CHIRP thing I guess. It confused me for quite a while since it is based on the settings from RX/TX tone modes, and not a setting itself. Same for tone-mode. Again this follows from RX/TX settings. But again, this is something in CHIRP.
• the prompt in the py file could be adjusted, it still says 'settings' is not available.
• I have nothing against Harold, but perhaps the credits for exploring the settings and initial work there could be set to me :)

There is one complaint: your original py took 2.5 seconds to download the memory. The latest one takes 9.5 seconds. Did you increase some timeout ?

73 Henk PA3CQN

E. van Puffelen wrote:

Dear Pavel; thanks for your work!
Memory reading seems to be ok; but "setting" shows an empty space.
The previous "my" file did show "basic" setting options.
73, Emiel

Emiel, works ok here too. What version of chirp are you using?

Henk Groningen wrote:

• I have nothing against Harold, but perhaps the credits for exploring the settings and initial work there could be set to me :)

I hadn't noticed those comments with my name. I'd agree the second mention (around line 396) should be you.

Harold Hankins wrote:

Henk Groningen wrote:

• I have nothing against Harold, but perhaps the credits for exploring the settings and initial work there could be set to me :)

I hadn't noticed those comments with my name. I'd agree the second mention (around line 396) should be you.

TNX..

By the way: did you ( or Dmitry )notice an increase in download time? Or is it just me?

I just timed it, from hitting OK until the download completes takes about 6 seconds for me.

The original driver took 2.5 seconds because it was only downloading the first 386 bytes of the eeprom. The current one downloads the full 2048 bytes in the eeprom to get the version/model info that's near the end of the eeprom.

Yep, discovered it in line 40.
Hmm, there is certainly an advantage in correctly identifying the device. But there is also an advantage in speed ...
But programming is a once in a time event, so not really a big thing

CHIRP daily-20171204 (latest) here on win 10 64.
The previous file my-bf-t1.py did work ok!

Maybe it is something very specific for my computer... best to ignore as so many other have no problems

Emiel,

Maybe some setting in your radio is a problem for the settings tab.

Try reading from the radio, saving the img on your hard drive, and then posting it here. I'll load the image into one of my radios and see if it has the same problem.

Thank you for your work!
When I export/import .csv file using bf-t1.py in #138, it raises 'List index out of exception'.

Can you check?

Wookhyun Shin,
Export/import .csv file works for me.
Perhaps the following will help:
Remove all settings the program. Delete file +chirp.config+ in "%APPDATA%\CHIRP"

Harold Hankins wrote:

Emiel,

You have an invalid setting in the file, the normal 470MHz upper limit is set to 480MHz.

Use the browser to change uhfh to 470 as in the attached, save the file, and then open it again. That should make it work.

That is indeed the problem. test.py which I uploaded does not include the bandlimit settings, thats why it works for Emiel. I
suspected the problem to be in that setting, since it is the only fundamental difference with Pavel's version.

Dmitry Milkov
Thank you. I've removed all settings but it didn't solve the problem.

I figured out rToneFreq, cToneFreq was empty when I exported the settings.
After I update the values using GUI it didn't happen again.

Pavel,

Sorry but ran into a major problem: tuning steps.
In the memory table you cannot enter values like 430.237500, that is 6.25 kHz steps. The BF-T1 itself rounds to 5 kHz and 6.25 kHz steps.
Somehow when you enter a value in the table it is checked against valid steps, and by failing to find them rounds to 5 kHz steps. If you right click and select properties you can enter 6.25 steps. Could not find a quick solution.
In the UVB5 py there is an array UVB5_steps , but a simular BFT1_steps array in BF-T1.py does not work.
Do you know how to solve this?

73 Henk PA3CQN

Dear all,

Yes... after setting upper UHF to 470 the settings tabs works now with bf-t1.py

The 9100 software allows 130-174 and 400-520. so setting upper UHF to 520 in Chirp will solve all problems users (like me!) can cause by doing this. There are many reasons why it is better not to use these higher limits; in practice many persons will try it. like to find out extended receive options.

Thanks for adding BF-T1. This Chirp version is already far superior to the 9100 program. Like cutting and pasting channels from a generic file to the BF-T1 is really nice!

Pavel, disregard my previous complaint about the frequency. On my laptop it works ok.
So must be my fault, perhaps damaged image or something like that.
Strange, can't explain it. But false alarm, sorry.

Is it possible to add an option set the bandwidth for "FM" (broadcast) to narrow (NFM)? Would be nice for 70 MHz/4m. Or is it a separate fixed, wide receiver?

Emiel v.P. wrote:

Is it possible to add an option to set the bandwidth for "FM" (broadcast) to narrow (NFM)? Would be nice for 70 MHz/4m! Or is it a separate fixed, wide receiver?

Henk,
Excellent!
You need to change the Band limits to 130-174 and 400-520.
The 9100 software allows you to do this!
Thank you.

Dmitry,

Bandlimits and Baofeng has been a longstanding debate. Most likely, like my UV-B5, it can even be set to extend into 220 on VHF ( yep, confirmed ! but very poor performance ), smack in the middel of EU DAB+.
But .. the endstage is not designed to cope with this extended range, and spurious ( not that good to start with ) is gigantic.
So the question is: do we allow responsible persons ( e.g. HAM operators ;-) ) to receive outside of the standard limits, or do we restrict
the limits for the more casual user?
I am inclined to remove the bandlimits setting alltogether. It is still possible to set the limits through the browser, but at least that is a bit more complicated.

Henk,
Thank you. But. I use standard frequencies.
I wanted to chirp all the possibilities of the OEM software.
I am sorry for my English.

Dmitry,

Yeah, it's just a bit of fun to build-in an easter-egg. Only couple of lines.
Maybe Pavel will keep it, maybe not. I's up to him, as is the choice to keep the special channels solution.

I would not use it out of limits, 70 cm is what I bought it for, and I'm allowed to use. And maybe sometimes with 0.5 W on PMR, semi-legal. Like I said, it doesn't really function well outside the limits, and with prolonged use -may- will damage the set.

Anyway, has been fun tinkering with the driver. Never used Python before, and only had the excisting py files to work it out. Nice brain-teaser.

73 Henk PA3CQN

Hi to all.

I'm away but informed via mail, I'm integrating all the suggestions and comments and also the special channels hack from Henk, I will come back tomorrow with a final driver and also a patch for support on chirp for the developers queue.

Thanks to all for helping me to bring another radio to chirp.

I think it's mature enough to go now to he main chirp.

73 Pavel CO7WT

Thank you Pavel.

Hello everybody.
Pavel, is this a mistake?
This is bf-t1.py - Finas driver, this is the one sent to the devel queue for inclusion in next Chirp. (28,56 КБ) Pavel Milanes, 22.12.2017 01:47
!http://i12.pixs.ru/storage/7/2/0/Image1png_2791020_28749720.png!

simple solution

533 rf.memory_bounds = (0, self._upper)

should be

533 rf.memory_bounds = (1, self._upper)

Thanks for the detail, I will check It, 73

There may be an issue setting the FM frequency. Steps to duplicate:

Download the current code plug¶

Navigate to Settings -> FM Radio¶

In the FM Station box, enter: 97.1¶

Upload the code plug¶

View the FM frequency on the radio or download the code plug and you will see the FM frequency was written as 97.000

If you instead enter 97.100 it will store correctly, but I don't think you should have to append the trailing zeros.

Lance Clarke wrote:

There may be an issue setting the FM frequency. Steps to duplicate:

Download the current code plug¶

Navigate to Settings -> FM Radio¶

In the FM Station box, enter: 97.1¶

Upload the code plug¶

View the FM frequency on the radio or download the code plug and you will see the FM frequency was written as 97.000

If you instead enter 97.100 it will store correctly, but I don't think you should have to append the trailing zeros.

Will check, tks

Pavel,Lance

I think this will solve it:

    def apply_fm_freq(setting, obj):
        setattr(obj, setting.get_name(),
            int(setting.value.get_value()*10) - 650)

Support for this Radio has been included on the main Chirp.

Also a patch for last bugs (Channel Zero and FM decimal) has ben sent to the dev queue, so wait for a fix in the forthcoming days.

Have a Happy New Year to all.

73 Pavel CO7WT.

Nice work all, and esp. Pavel for starting this effort.
Pavel, I hope the set donated to you will arrive soon.
It's just a fun set to play with despite it's size.

73 Henk PA3CQN

Pavel,

Sorry but there is still a small error in the fm-callback

line 833:

int(setting.get_value() * 10) - 650)

should be

int(setting.value.get_value() * 10) - 650)

Hi to all.

I confirmed the Henk notice on the bug I introduced, sorry. I will patch it ASAP.

HNY to all.

73 Pavel CO7WT.

Hi Pavel / All,

Had not been reading this for a couple of days after a serious crash ( fried uP/MB/PS ).
Seems all is working fine now. I agree this issue can be closed.
Has been a nice project to be part off, and contribute to.

Now it's time to investigate the hidden stuff ..

73 Henk PA3CQN